Remarks 



Status of the Claims 

Claims 1-28 and 31-43 are pending in the application. All claims stand rejected. 
By this paper, claims 18, 21-23, and 26 are amended. Reconsideration of all pending 
claims herein is respectfully requested. 

Claim Rejections - 35 U.S.C. §102 

Claims 1-28 and 31-43 were rejected under 35 U.S.C. §102 as being anticipated 
by McCoy (U.S. Pub No.: 2001/0037311). The rejection of each pending claim is 
traversed for the reasons set forth below. 

It is well established that a claim is only anticipated under 35 U.S.C. § 102(b) if 
" each and every element as set forth in the claim is found, either expressly or inherently 
described, in a single prior art reference." MPEP §2131 , citing Verdeqaal Bros, v. Union 
Oil Co. of California , 814 F.2d 628 at 631 (Fed. Cir. 1987); emphasis added. "The 
identical invention must be shown in as complete detail as is contained in the . . . claim ." 
MPEP §2131, citing Richardson v. Suzuki Motor Co ., 868 F.2d 1226 at 1236 (Fed. Cir. 
1989); emphasis added. 

For at least the following reasons, McCoy fails to teach each and every element 
set forth in any of the pending claims. 

First, McCoy fails to teach the limitation recited in claim 1 of "an account holder 

creating and associating a plurality of tokens with a financial account by recording the 

plurality of tokens in an electronic token log...." McCoy's token is a payment "coin" 

"which is preferably implemented as a data string containing (at a minimum) the 
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following elements: a large random number 90, the denomination of the coin 92, and the 
currency ID 94 of the coin." McCoy, at If [0067]. Therefore, McCoy's token contains the 
actual monetary value (see FIG. 6), and does not need to be stored in a token log as 
recited in the pending independent claims (e.g. claims 1 , 3, 5, 31 , 40, 41 , 42). 

Second, since McCoy's "coin" token contains a pre-authorized monetary value, 
the client agent (i.e. buyer) presents the token to the broker agent (i.e. vendor) (Fig. 5B 
item 80) and the broker agent can verify the token directly (Fig. 5B item 81) without the 
need to contact the payment agent for authorization . This contrasts sharply with the 
claimed limitations, which require (e.g., claim 1 as previously amended) that the "vendor 
is to provide the token, the indication of the account, and information about the 
transaction to the computing device of the authorizing institution, which authorizing 
institution's computing device provides the vendor with transaction authorization based 
on the token being found to exist in the token log." Similar limitations are also recited in 
independent claims 3, 5, and 31 . 

Third, independent claim 1 recites, among other things, the limitation of "an 
account holder creating and associating a plurality of tokens with a financial account by 
recording the plurality of tokens in an electronic token log, which electronic token log is 
accessible by a computing device of an institution that is responsible for authorizing one 
or more transactions involving the account...." Similar limitations are also found in 
independent claims 3, 5, 31, 40, 41, and 42. McCoy's teaches no such "electronic 
token log." The only place McCoy teaches tokens being recorded is in a "spent coin" 
database, which database is only accessible by the authorizing institution (payment 
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agent), and not accessible by the account holder. McCoy, at [0067] and Fig. 5B item 
86. 

In addition, the transaction authorization process taught by McCoy contrasts with 
what is recited in the claimed invention. The October 8, 2008, response to the Office 
Action dated July 2, 2008, contained the following graphic representation of a dual- 
channel authorization request system. 

Figure A: Dual-Channel Authorization Request System (corresponds to FIG. 1 and FIG. 
2 of the present disclosure) 




The entities involved in Figure A are as follows: 

• Entity B (buyer / account holder) - an entity desiring to facilitate a transaction by 
instigating the authorization of the transaction. 

• Entity F (financial institution with the buyer's financial account) - an entity 
responsible for authorizing (or rejecting) the transaction. 
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• Entity V (vendor the buyer is purchasing from) - an entity who is the recipient of the 
transaction and the transaction authorization. 
As illustrated above, the authorization process includes: 

• Step 1 : Buyer creates and stores a new token in a Token Log (TAL) accessible 
by the Financial institution. 

• Step 2: Buyer provides the token and account information to the Vendor. 

• Step 3: Vendor provides the token and the account information to the Financial 
institution in order to obtain transaction authorization. 

• Step 4: Financial institution checks TAL as well as account database (ADB). 

• Step 5: Financial institution provides Vendor with authorization, as appropriate. 
In contrast to the illustration above, and the limitations of the pending claims, the 

following is a graphic representation of the transaction authorization process taught by 
McCoy, specifically taught in [0067] and FIGS. 5A and 5B. 
Figure B: Transaction Authorization process taught by McCoy 
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As illustrated in Figure B, McCoy describes the following steps. 

• Step 1 : Buyer ("client agent") creates a new token but does not store it in a 
Token Log (TAL) accessible by the Financial institution. McCoy's invention has 
no such Token Log. Instead, Buyer [0067] "may retain the coin until ready to 
make a payment." Accordingly, McCoy fails to teach the limitation recited in 
independent claims 1 , 3, 31 , 40, 41 , and 42 that the token is recorded "in a token 
log". 

• Step 2: Buyer provides (step M4) token to the Vendor ("broker agent") but does 
not provide account information (since the token itself has monetary value) to the 
Vendor. Accordingly, McCoy fails to teach the limitation recited in independent 
claims 1 , 3, 5, 31 , and 42 that require "the account holder initiating a transaction 
involving the financial account by providing one of the tokens previously recorded 
in the electronic token log and an indication of the account to a vendor". 

• Step 3: Vendor provides (step M5) token (but not account information) to the 
Financial institution ("payment agent") and the Vendor does not wait for 
transaction authorization from the financial institution. Accordingly, McCoy fails to 
teach the limitation recited in independent claims 1, 3, 5, 31, 40, and 42 that 
require that "the vendor is to provide the token, the indication of the account, 
and information about the transaction to the computing device of the authorizing 
institution, which authorizing institution's computing device provides the vendor 
with transaction authorization based on the token being found to exist in the 
token log". 
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• Step 4: Financial institution previously checked the account database (ADB) (in 
step M2) and does not check a Token Log populated by the Buyer. Accordingly, 
McCoy fails to teach the limitation recited in independent claims 1 , 3, 5, 31 , 40, 
and 42 that require that the "authorizing institution's computing device provides 
the vendor with transaction authorization based on the token being found to 
exist in the token log ". 

• Step 5: Financial institution does not provide the Vendor with authorization, as 
appropriate, since the Vendor can verify the token validity independently ([0067] 
and FIG. 5B step 80). Accordingly, McCoy fails to teach the limitation recited in 
independent claims 1 , 3, 5, 31 , 40, and 42 that require that the "authorizing 
institution's computing device provides the vendor with transaction 
authorization". 

Further, it is clear that the "spent coin" database is different from the claimed 
Token Log (TAL) in various ways [0067]: 

• The "spent coin" database is populated by the Financial institution ("payment 
agent"), not by the Buyer ("client agent"). In contrast, claims 1 , 3, 31 , 40, 41 , and 
42 recite "an account holder creating and associating a plurality of tokens with a 
financial account by recording the plurality of tokens in an electronic token log". 

• The "spent coin" database is not populated until after the transaction has been 
authorized (Figure B step M8). In contrast, the claimed Token Log is populated 
before a transaction is initiated (Figure A step 1), as recited in claims 1 and 40, 
which require "the account holder initiating a transaction involving the financial 
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account by providing one of the tokens previously recorded in the electronic 
token log". 

• The "spent coin" database is checked (Figure B step M6) after the user's account 
balance has already been decreased (Figure B step M2). In contrast, the 
claimed Token Log is checked (Figure A step 4) before a transaction is 
authorized (Figure A step 5), as recited in claims 1 , 3, 5, 31 , 40, 41 , and 42, 
which require that "the vendor is to provide the token, the indication of the 
account, and information about the transaction to the computing device of the 
authorizing institution, which authorizing institution's computing device provides 
the vendor with transaction authorization based on the token being found to 
exist in the token log". 

Because McCoy does not disclose each and every limitation of any of the 
pending claims, McCoy does not anticipate or render obvious claims 1 -28 and 31 -43. 

Conclusion 

For at least the reasons set forth above, independent claims 1, 3, 5, 31, and 40- 
42 are patentably distinct over the prior art of record. All other claims are dependent 
upon one of the foregoing claims and are therefore patentably distinct for at least the 
same reasons. A Notice of Allowance is respectfully requested. 
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Respectfully submitted, 



STOEL RIVES llp 

One Utah Center Suite 1 1 00 

201 S Main Street 

Salt Lake City, UT 84111-4904 
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Facsimile: (801)578-6999 



By /Korv D. Christensen/ 
Attorney for Applicant 
Registration No. 43,548 



21 



